BCI NET 2/BCI NET 2.iso/archives/demos/misc/walls17.lha/walls17.txt

Text File | 1995-02-16 | 11.6 KB | 253 lines

 jgggggg     gggggg       ggggg              jgggg    gggg,     D.H.1994
  "####"     "0###F       "##@"               "###    "###F
   9###_       ###k       j##                  ###     ###F
    ###&      _####_      0#"                  ###     ###F
    3###p     d####k     j#@                   ###     ###F
     0###    j##9###_    ##    _ggggggg_       ###     ###F     _gggggg_
      ###_   ##  ####   J#F    ###" "N##k      ###     ###F    g#F" 7###
      0###  J#F  ?###L  ##     "^"    ###      ###     ###F    ##h__ ""
       ###L ##    0###_d#F     __ggM#N###      ###     ###F    9#####g__
       9###0#F    `###N##     g##@"   ###      ###     ###F      "@NN###_
        ####@      0###N     j###     ###      ###     ###F   _gg_   "###
        ]###        N##F      ###L___dN##L_   j###_    ###L   0##&___g#N'
         #NF        7N#        9NNNNP" @N#@  ]NNNNNF  NNNNN#   "N#NN#@P

                  Walls V1.7


Raycasting.  Oh yes, it seemed kinda cool at the time.  Walls is not a
new routine.  The raycasting-code in Walls was written around newyear
92-93 and was optimized for a demorelease later, in march 94.  The
algorithm isn't that fast (even if I thought so at the time :-) simply
because raycasting isn't a very fast technique.  The maps are pretty
limited, and the routine can't handle anything but perpendicular
walls.  But it does have other advantages.

For anybody who wonders (and I've been asked this many, many times)
Walls was programmed in 100% assembler (Trash'mOne 1.7).  So there.

The demo should be runnable on just about any Amiga.  I've tested it
on my own computers (A500 + A1200) but I can't guarantee anything
about any other setups.  The program contains occational bugs and will
crash every once in a while (hopefully not too often though).  If you
can't live with that, don't run it.

What is it then?  It's basically the same routine as found in the
files "1frame.exe" and "2planes.exe" in the original Walls-package,
only with a little more colors, a background-horizon, objects and
...hmmm...  "floors" I guess.  If you want to know more, read the part
about the code later. Or run the demo.




The Editor (also read the warnings later!)

Whoa!  Yes, it's true!  Walls now allows you to create your own
worlds!  Actually, the whole editor-thing was hacked together in two
nights recently, just because after 6 months of inactivity I realised
that since I will never continue to improve the routine anyway I might
just as well make it publicly available.

Just use the mouse to paint walls of your choice ; draw with the left
button and delete with the right.  Both mousebuttons will exit each part.

After you have painted the map, you can place some objects into it.
I've had the object-handling routines ready for almost a year now, so
I thought I might include a small editor for these as well.  The
objects you can add are only bouncing balls, but theoretically the
routine can handle any number of different objects (sizes, colors
etc.) just as long as there is free chipmem (the bob is prescaled/
colored in the beginning of the routine and thus takes up a lot of
chipmem).  I decided to keep the memory-requirements low so that even
A500-users will be able to run the demo.  After all, this isn't
exactly state-of-the-art code anymore anyway, and many of the people
who liked V1.0 were A500 owners who were happy to get hold of
something new that worked on their machines... The original idea was
to make the engine render all objects as vectorobjects (I _hate_
bitmaps ala' Doom.  If it's 3d then it's 3d - IMHO bitmaps destroy the
sense of 3-space) but I never got down to actually completing the
vectorengine.

And finally you can add shadows to the floor.  This was one of the
first ideas I got about floors, since texturemapping the whole floor
was far too CPU-intense for an A500 (which was the machine I started
coding Walls on).  The shadows are simple two-dimensional blitter
outlined polygons, but they look kinda good anyway if you ask me.  You
can select from 8 different objects by cycling them with the right
mousebutton.

A maximum of 256 balls and 256 shadows can be inserted into the maze
(this is just the reserved amount of space, theoretically there are no
boundaries), after that the routine will most likely crash. :-)

The shadowobjects to choose from are:

1 - Right Arrow
2 - Down Arrow
3 - Left Arrow
4 - Up Arrow
5 - Square
6 - Triangle
7 - Cross
8 - Circle (ballshadow)

Pretty sophisticated, huh? (yeah yeah, I'm no artist :-)
You can combine many shadows on one square if you wish.



Limitations and warnings

The routine isn't very thoroughly debugged.  It will probably crash
every once in a while, but that's life.  It's pretty stable on my
machine though (A1200+FAST), and it should work fine on A500s too
(though slightly slower).

Every wallsegment will have to include at least one corner!  That is,
no walls can be standalone ; you will always have to make at least one
turn in each segment.  This is due to the way my cheat works, not much
to do about it.  Making such walls will not crash the machine, but the
wallsegment will become invisible if looked upon from the "wrong" angle.

IE Don't make walls like this   xxxxxxxx  or this  x
                           x
But make them like this   xxxxxxx    x           x
                x    x           x
                x    x
                     xxxxx

IMPORTANT : *DO NOT* leave infinityholes in the map!!! The whole map
must always have a fixed boundary - if a piece of the outermost border
is missing the raycaster will start looping in memory and your
computer will probably crash.

Balls and shadows can only be placed in the center of each square.
(multiples on one square if you wish).  This is not a limitation in
the routine (it was programmed to be modular, and can even handle
large shadows covering several squares) but it was the easiest way to
implement objects in the editor.  Besides, the sorting-algorithm have
problems with balls placed very close to a wall anyway.

You can't save your maps.  Tough luck.  I did't have any source for
diskhandling lying around (and some peeking in amiga.demos gave no
result) so I let it be (this release _is_ just a quick hack).  If you
have some finished source for save/load, mail it to me then I might
release a V1.71 with save/load map options.

If anybody wonders why the floorshadows get deformed when they get
real close, it's because I don't z-cut them - I simply handle all
negative coordinates as zeros. The original shadow routine was
written about 8 months ago (my intention was to add z-cutting
later) but I just can't push myself into manipulating the routine
anymore... Everything is buffered into a million different places
(modularity, you know :-) and I don't have the time to trace down
the routine again. I really should start documenting my source...



The code

..is probably pretty ugly.  I do not take over the display or do any
of all that stuff-you-always-should-do.  I haven't coded actively
since I bought my A1200, and back in those days nobody cared about
systemfriendliness as long as the routines worked on a warmbooted
A500 :-).  Actually, I don't even kill interrupts, so if you want to
you can have Delitracker playing your favourite module in the
background while you run around in the maze.  Who says you can't use
softwaremixing in a game?  (try playing your favourite s3m in the
background and be amazed!)

The code is old and ugly.  If there ever is a Walls V2.0 I'll recode
the whole shit from scratch, but I hardly think I'll ever bother.
Dammit - I'm getting old too!  I just don't have the patience to sit
around coding all day any more.  I now know of a new algorithm that is
even faster than the one I use at the moment (not BSP, not z-buffered
vectors), and that would also allow nonorthogonal walls and doors.  I
also have a pretty neat idea about how different level floors could be
included...

Most of the CPU time is currently spent waiting for the blitter
(probably >50%).  This is because I coded the original routine on
an A500 without fastmem and didn't think about splicing the code in
a smarter way.  Lots of speed could theoretically be gained here.

On AGA-computers bitplane-modulos and sprites could be used to speed
up much of the stuff that is now being blitted, and also increase the
speed of the routine a lot.  Some of you might not see the point in
doing this - "why do crappy planar-walls without texturemapping when
tmapping obviously _can_ be done?".
Answer: Speed.
A new routine based on the AGA chipset + FASTmem and better algorithms
could be KICK ASS! Just imagine what you see in this routine, but with
non-orthagonal walls and windows, differently colored wall-segments,
moving lightsources and dozens of vector-objects flying around in 20fps.
It could be done, possibly even with different height floors. But you
would have to forget about TMapping.



On wolfie-clones

 My personal opinion is that many Amiga-coders are just too
PC-fixated. Sure - PCs can handle very complex texturemapping without
sweat (hell, when you look at PC-demos you'd think that's all you can
do with them!) but that's just not the Amiga's strong side. That's not
saying I don't like all the wolf-clones that has appeared on the Amiga
during the last year(s) - hell no! I love them! It's always nice to
see how far the Amiga can be pushed. But I'm somewhat surprised at the
incredible lack of originality many coders seem to suffer from. Yeah,
Doom was real nice, but what's the point in doing the same thing again
and again if you never have anything of your own to add?

Walls is getting old. This routine is very far from state of the art
today (just looking at the stuff Bomb, John Hendrix and Parallax (to
pick but a few) have done), but I still somehow like its simplicity.
You could do some tremendeous stuff on the Amiga if you just
concentrated on the things the Amy can do well instead of trying to
imitate the PC.



The soap opera

After the release of Walls V1.0 I got a lot of response from people
who liked it (hi everybody!) and among the emails there was one
particularly interesting ; a proposal for a deal from a software
company in Canada.  The deal was almost too good to be true (it was),
and what they said was basically that they wanted me to continue
working on the routine together with one of their programmers and make
a game out of it.  Cool.

So, I continued with improving the routine at the same time as I
started negotiating a deal with the company. We got everything sorted
out, money, royalties, a schedule... But all of a sudden they stopped
replying to my mails. At this point the routine was about where it is
right now (I worked on it during weekends and evenings for about two
months) and considering the amount of work I had already put into it I
got kinda pissed. Wouldn't you?

Realizing what was about to happen I put the whole project on ice and
started bugging my contact with mails so that I at least would get to
know what was going on.  I had been promised a fair amount of money
and some hard/software that should have been posted ages ago by then,
but naturally, I never received any of it.  After a couple of months
of fruitless waiting I finally got a reply where my contact explained
that the company was in financial trouble and all projects had been
cancelled.  Hell - for all I know the company never even existed.  A
pity really.  I had _soo_ many good ideas for the game, and the guy I
corresponded with seemed like a real nice fella.  I still think it was
a shitty thing of them to do - they could have at least kept me
informed!  Hmmm...  That's just life I guess.  By then I was already
so tired of everything that had to do with the game that I decided to
forget all about it, and I did.  This is it.

Oh well. Enough crap for now. Run the program now if you haven't
already - I hope you'll all have fun with it!


.. Mats
   [e-mail]
   http://www.hut.fi/~mknip